Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Extending the test procedure with a dynamic browse

In this section, you’ll apply a few of the things you just learned to add a dynamic browse to the procedure with the dynamic temp-table.

To extend the sample procedure with a dynamic browse:

Open the h-testDynTT.p procedure and save a new version of it as h-testDynBrowse.p.
Add a variable definition at the top for a browse handle and also a frame definition for a frame to hold the browse:

DEFINE VARIABLE hBrowse AS HANDLE      NO-UNDO. DEFINE FRAME BrowseFrame WITH SIZE 80 BY 10.

Remove the REPEAT block from the procedure that walks through the temp-table records using the dynamic query and displays them. Instead, you’ll display them in a dynamic browse.
Add a CREATE BROWSE statement after the QUERY-PREPARE. It will be the only object in the frame, so it can be at ROW 1 and COLUMN 1. Its WIDTH needs to be slightly less than the frame to allow for the frame border. Parent it to the frame and assign the dynamic query to it. Make it SENSITIVE and VISIBLE, and give it SEPARATORS between columns but no ROW-MARKERS at the beginning of the row:

CREATE BROWSE hBrowse     ASSIGN ROW = 1 COL = 1            WIDTH = 79 DOWN = 10            FRAME = FRAME BrowseFrame:HANDLE            QUERY = hQuery            SENSITIVE = YES            SEPARATORS = YES            ROW-MARKERS = NO            VISIBLE = YES.

To get started, try adding all the columns from the temp-table buffer except for a handful that you exclude, using this statement:

hBrowse:ADD-COLUMNS-FROM(hTTBuf, "SalesRep,Country,address,Address2,State").

Note that you cannot pass the dynamic temp-table name as the table identifier for this method. Even though you do give the temp-table a name when you prepare it, that name is not available to the method. You must pass the handle to a buffer for the temp-table, either its DEFAULT-BUFFER-HANDLE or another buffer you’ve defined for it.

Enable everything in the frame and wait for the user to close the window so that the user can manipulate the browse when the window comes up:

ENABLE ALL WITH FRAME BrowseFrame. WAIT-FOR CLOSE OF CURRENT-WINDOW.

Run the procedure. You should see all the Customers in New Hampshire with all the fields except the ones you excluded:

To try adding specific columns to the browse:

Remove the ADD-COLUMNS-FROM method and instead add these four statements to add these four columns to the empty browse:

hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("Sequence")). hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("CustNum")). hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("Name")). hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("RepName")).

Run the procedure again. You should see just the four columns you specified:

Browse columns and validation expressions

This section discusses the relationship between validation expressions and browse colmns.

To see an example of this relationship:

Add the SalesRep field to the column list, with this statement:

hColumn = hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("SalesRep")).

Run the procedure. You should see this error message:



The reason for this error is that in the Sports2000 database there is a validation expression defined on the Customer.SalesRep field, which the temp-table column has inherited. This validation uses a CAN-FIND expression to check to make sure that the value in the SalesRep field matches the SalesRep field in a record in the SalesRep table. The field SalesRep.SalesRep (it’s somewhat confusing that the table name and field name are the same) is the primary key for this value. Customer.SalesRep is the foreign key. Progress cannot process a CAN-FIND for a dynamic browse column, so if you want to include such a column, you need to exclude the column validation.

To do this, add a statement to blank out the validate expression before you add the column to the browse:

hTTBuf:BUFFER-FIELD("SalesRep"):VALIDATE-EXPRESSION = "". hColumn = hBrowse:ADD-LIKE-COLUMN(hTTBuf:BUFFER-FIELD("SalesRep")).

To see another variation, add a calculated column to the browse. This column will hold the difference between the Customer CreditLimit and Balance fields. It’s a DECIMAL field with no extent and a label of Available. Place the new column in position 4 within the list of browse columns:

hColumn = hBrowse:ADD-CALC-COLUMN("DECIMAL","ZZ,ZZZ,ZZ9.99",0,"Available",4).

To populate the field for each row in the query, you need to define a ROW-DISPLAY trigger for the browse. You can add the trigger as a separate ON ROW-DISPLAY OF hBrowse statement, or in a TRIGGERS block at the end of the CREATE BROWSE statement:

CREATE BROWSE hBrowse       .       .       .   VISIBLE = YES   TRIGGERS:     ON ROW-DISPLAY        hColumn:SCREEN-VALUE =           STRING(hTTBuf:BUFFER-FIELD("CreditLimit"):BUFFER-VALUE         - hTTBuf:BUFFER-FIELD("Balance"):BUFFER-VALUE).   END.

When the trigger executes, the handle of the column must be in the hColumn variable. You need to define the ROW-DISPLAY trigger before the calculated field is added to the browse, and before the query is opened. You can modify the SCREEN-VALUE and certain other attributes of any field within the trigger.

Move the QUERY-OPEN method after the statements that create the browse and its columns so that rows are initialized properly with the calculated value:

hColumn = hBrowse:ADD-CALC-COLUMN("DECIMAL","ZZ,ZZZ,ZZ9.99",0,"Available",4). hQuery:QUERY-OPEN().

If you open the query before you create the browse and its trigger, the first rows of the query appear in the browse viewport, but the calculated field isn’t assigned to them. Only when you scroll down through the browse do the values for the calculated field appear. This is why it’s important to define the trigger and add the column before you open the query.

Run the procedure: